昨天分享了團隊決定啟動專案後的規劃階段，今天要來聊聊當我們真正開始執行時發生的事情。這是一個關於「理想與現實的差距」的故事，也是我們學會如何在AI協助下，找到真正解決問題方法的重要轉折點。
決定啟動專案後，我們的第一步是進行實地訪談。我提供給Claude目前已知的業務流程與痛點圖，並請他協助準備訪談大綱：
我的Prompt：
"這是我原本業務夥伴作業的流程圖，以及大略知道的痛點，請幫我設計一份針對門市銷售人員的訪談大綱，根據流程幫我規劃問題，訪談業務夥伴們在現有系統中遇到的狀況，或是困擾的地方。訪談對象是門市的業務同事。"
Claude產出的訪談大綱：
我當時看著這份大綱，覺得：「結構很完整，好像跟我想像想問的差不多，應該能收集到需要的資訊。」
在正式訪談前，我利用週末時間到門市實地觀察。這個決定證明是非常正確的，因為親眼看到的和想像中的差距很大。
從「接客」到「付款」，我發現整個流程遠比想像中複雜：
接客階段：
產品諮詢階段：
建立客戶&訂單階段：
第一個重要發現：每個環節的時間差異很大，而且充滿變數。
使用Claude準備的問題進行訪談時，我發現了一個關鍵問題：
AI的問題：「目前建立一張訂單哪些步驟特別耗時？」
實際對話：
我意識到，AI擅長產生邏輯性的問題，但缺乏引導對方開口的技巧。
我改變了提問方式，從抽象轉向具體：
改為： 「昨天那個買沙發的客人，你記得從他進門到最後付款大概花了多長時間嗎？」
這樣一問，同事立刻打開話匣子：
同事A：
關鍵學習：具體情境比抽象問題更能引出真實經驗。
當我訪談第二位同事時，得到了完全不同的回饋：
同事B：
經過深入了解，我發現答案浮動的兩個主要原因：
原因一：每個人的系統操作方式不同
原因二：客戶購買情境差異很大
第二個重要發現：人的因素比系統因素更複雜，而且難以標準化。
經過兩輪訪談後，我們意識到一個重要問題：不可能訪談到所有人，而且正式訪談得到的回饋往往不是最真實的。
實際情況是：
真正的痛點，其實來自於平時的觀察和收集：
日常工作中的抱怨：
非正式聊天中的反饋：
實際工作場景的觀察：
結合訪談內容和平時觀察，我們歸納出幾個主要的共同痛點：
經過兩輪訪談，我們發現了一個重要問題：
訪談的變數太多，無法量化
訪談的變數太多，無法量化
我和老闆討論這個困擾時，老闆提出了一個想法：
老闆：「我在想，有沒有什麼量化的方式，可以做一些紀錄，無論是現在或是之後改版後，可以有個宏觀的角度去分析這件事」
我：「你是說要量化這些流程？」
老闆：「對，如果我們能知道每個步驟實際花了多少時間，就能找到真正的問題所在。」
這個想法讓我們有了新的方向思考。
有了量化的想法後，我帶著這個問題去請教Claude：
Prompt：
"我們進行了門市人員訪談，但發現每個人的回饋差異很大，而且難以量化。現在想要改用量化的方式來了解真實的系統使用狀況，請問有什麼可行的建議？"
Claude的建議：
帶著Claude的建議，我和老闆進一步討論實際的可行性：
老闆的擔心：「量化聽起來很理想，但我們可以怎麼做？」
我的考量：「還有一個問題是，門市人員會願意配合嗎？會不會覺得被監控？」
老闆：「這些都是要解決的問題，但如果我們能找到不影響正常營運的方式，量化絕對是對的方向。」
經過討論，我們達成初步共識：量化方向是對的，但需要找到最可行的實作方式。
通過這次從訪談到量化的思考轉變，我學到了幾個重要概念：
內部討論產生關鍵洞察
當我們陷入訪談結果太主觀的困擾時，和老闆的討論讓我們想到了量化的新方向。
問題定義比解決方案更關鍵
從「如何改善系統」轉向「如何量化問題」，改善系統是必然，但是量化會讓我們更明確我們要改善的方向。
AI是驗證想法的好工具
有了量化的想法後，AI協助我們思考具體的實作可能性和注意事項。
數據勝過主觀感受
當主觀訪談無法提供明確答案時，客觀數據是更可靠的選擇。
現在我們確定了方向：要做量化，但還需要找到最適合的執行方式。
接下來的挑戰是：如何在不影響現有營運的情況下，建立一個可行的時間記錄機制？
iThome鐵人賽
看影片追技術